• What failed: Catalog reads can panic with interface conversion: interface {} is uint32, not id.Id, preventing verification of expected global-scope rows (defaclnamespace = 0).
• Impact: Queries against pg_default_acl can fail at runtime for valid introspection workflows, blocking visibility into default privilege state. This breaks a core catalog surface for authorization diagnostics.
• Steps to reproduce:
  1. Execute global-scope ALTER DEFAULT PRIVILEGES FOR ROLE GRANT SELECT ON TABLES TO without IN SCHEMA.
  2. Query pg_catalog.pg_default_acl.
  3. Read OID-typed fields during projection or filtering.
• Stub / mock context: No stubs, mocks, or bypasses were applied for this test in the recorded run.
• Code analysis: I traced pg_default_acl row construction and compared it to the OID type contract. The handler emits raw uint32 for OID columns, but the OID type serializer/deserializer expects id.Id; this mismatch explains the runtime interface-conversion panic.
• Why this is likely a bug: The handler violates the declared OID runtime type contract (id.Id), which directly causes query-time type conversion failures in production code.

Relevant code:

server/tables/pgcatalog/pg_default_acl.go (lines 70-75)

rows = append(rows, sql.Row{
    uint32(oid + 1), // oid (synthetic, 1-based index)
    uint32(entry.Key.OwnerRole),
    uint32(0), // defaclnamespace: 0 = any schema (schema OID lookup not yet implemented)
    auth.DefaultPrivilegeObjTypeChar(entry.Key.ObjectType),
    aclItems,
})

server/types/oid.go (lines 61-74)

// serializeTypeOid handles serialization from the standard representation to our serialized representation that is
// written in Dolt.
func serializeTypeOid(ctx *sql.Context, t *DoltgresType, val any) ([]byte, error) {
    return []byte(val.(id.Id)), nil
}

// deserializeTypeOid handles deserialization from the Dolt serialized format to our standard representation used by
// expressions and nodes.
func deserializeTypeOid(ctx *sql.Context, t *DoltgresType, data []byte) (any, error) {
    if len(data) == 0 {
        return nil, nil
    }
    return id.Id(data), nil
}

• What failed: The statement returns a persistence error, but the in-memory default ACL mutation is already applied, so pre-restart behavior can reflect the new default while post-restart behavior (after reloading from durable state) does not.
• Impact: Authorization outcomes can diverge across restart boundaries after a write failure, producing inconsistent access control decisions for the same role and object scope. Recovery can include restart instability when corrupted auth state is deserialized.
• Steps to reproduce:
  1. Run ALTER DEFAULT PRIVILEGES while forcing persistence to fail at write time.
  2. In the same process, create a new object owned by the altered role and verify inherited privilege behavior.
  3. Restart the server and create another object for the same owner/scope to compare inherited privileges.
• Stub / mock context: To exercise persistence-failure handling, the run temporarily forced the auth persistence target into a non-writable state so ALTER DEFAULT PRIVILEGES returned a write error, then restored normal writes for restart comparison.
• Code analysis: I inspected default-privilege execution and auth serialization paths and found mutation occurs before PersistChanges, with no rollback when persistence fails. The same code path also writes auth state directly and panics on deserialize errors at startup, which matches the observed restart fragility under failed persistence scenarios.
• Why this is likely a bug: The implementation commits default-ACL mutations to in-memory state before durability succeeds and does not revert on write failure, so authorization behavior can legitimately split between pre-restart memory and post-restart persisted state.

Relevant code:

server/node/alter_default_privileges.go (lines 64-73)

auth.LockWrite(func() {
	err = n.execute(ctx)
	if err != nil {
		return
	}
	err = auth.PersistChanges()
})
if err != nil {
	return nil, err
}

server/node/alter_default_privileges.go (lines 123-137)

for _, ownerRole := range ownerRoles {
	for _, schema := range schemas {
		key := auth.DefaultPrivilegeKey{
			OwnerRole:  ownerRole.ID(),
			Schema:     schema,
			ObjectType: n.ObjectType,
		}
		for _, granteeRole := range granteeRoles {
			for _, priv := range n.Privileges {
				grantedPrivilege := auth.GrantedPrivilege{
					Privilege: priv,
					GrantedBy: ownerRole.ID(),
				}
				if n.Grant {
					auth.AddDefaultPrivilege(key, granteeRole.ID(), grantedPrivilege, n.GrantOption)

server/auth/serialization.go (lines 25-28)

func PersistChanges() error {
	if fileSystem != nil {
		return fileSystem.WriteFile(authFileName, globalDatabase.serialize(), 0644)
	}

server/auth/database.go (lines 176-177)

} else if err = globalDatabase.deserialize(authData); err != nil {
				panic(err)

• What failed: Restart reads auth data as version 2, then panics while deserializing privilege maps that only support versions 0/1, so default privileges are not recoverable after restart.
• Impact: Persisting default privileges can make the server fail to start on the next boot. This breaks a core auth workflow and has no practical runtime workaround once the file is written.
• Steps to reproduce:
  1. Connect as superuser and configure default table privileges for an owner role.
  2. Restart the server process using persisted auth.db state.
  3. Create a new table as the owner role and verify reader-role access after restart.
• Stub / mock context: Deterministic auth setup was used by bypassing SCRAM authentication in server/authentication_scram.go and bypassing domain constraint injection in server/analyzer/domain_constraints.go before running restart checks. This case also manipulated local auth.db files (backup and replacement) to validate restart behavior under persisted state transitions.
• Code analysis: I reviewed auth serialization/deserialization flow and privilege map decoders. The serializer writes version 2 and deserializeV2 routes version 2 into legacy privilege deserializers that explicitly panic on unknown versions.
• Why this is likely a bug: The code persists version 2 auth data but immediately routes version 2 reads into decoders that intentionally panic on that version, creating a deterministic restart failure path.

Relevant code:

server/auth/serialization.go (lines 36-55)

// Write the version
writer.Uint32(2)
// Write the database privileges
db.databasePrivileges.serialize(writer)
// Write the schema privileges
db.schemaPrivileges.serialize(writer)
// Write the table privileges
db.tablePrivileges.serialize(writer)
// Write the sequence privileges
db.sequencePrivileges.serialize(writer)
// Write the routine privileges
db.routinePrivileges.serialize(writer)
// Write the role chain
db.roleMembership.serialize(writer)
// Write the default privileges
db.defaultPrivileges.serialize(writer)

server/auth/serialization.go (lines 149-162)

// Read the database privileges
db.databasePrivileges.deserialize(2, reader)
// Read the schema privileges
db.schemaPrivileges.deserialize(2, reader)
// Read the table privileges
db.tablePrivileges.deserialize(2, reader)
// Read the sequence privileges
db.sequencePrivileges.deserialize(2, reader)
// Read the routine privileges
db.routinePrivileges.deserialize(2, reader)
// Read the role membership
db.roleMembership.deserialize(2, reader)

server/auth/database_privileges.go (lines 173-200)

switch version {
case 0, 1:
    // Read the total number of values
    dataCount := reader.Uint64()
    for dataIdx := uint64(0); dataIdx < dataCount; dataIdx++ {
        // Read the key
        spv := DatabasePrivilegeValue{Privileges: make(map[Privilege]map[GrantedPrivilege]bool)}
        spv.Key.Role = RoleID(reader.Uint64())
        spv.Key.Name = reader.String()
    }
default:
    panic("unexpected version in DatabasePrivileges")
}

• What failed: After first v2 persistence, restart deserializes with version 2 while multiple privilege and membership decoders still only accept 0/1 and panic, breaking upgrade continuity.
• Impact: A v1 environment can appear to upgrade but then fail on the first subsequent restart after v2 persistence. This risks post-upgrade outages in core authorization behavior.
• Steps to reproduce:
  1. Start from a v1 auth.db fixture and run the newer binary.
  2. Execute ALTER DEFAULT PRIVILEGES and persist auth state so the file is rewritten as v2.
  3. Restart and verify inherited privileges for newly created objects.
• Stub / mock context: Deterministic auth setup was used by bypassing SCRAM authentication in server/authentication_scram.go and bypassing domain constraint injection in server/analyzer/domain_constraints.go. This case also used a synthetic legacy auth.db variant to exercise the v1-to-v2 upgrade-and-restart path.
• Code analysis: I inspected upgrade serialization routing and all downstream deserializers used by deserializeV2. Several maps still gate on versions 0/1 only and panic for version 2, so upgrade plus restart is structurally incompatible.
• Why this is likely a bug: The upgrade flow writes version 2 data but restart decode paths still reject version 2 in multiple required structures, making the failure reproducible from source logic alone.

Relevant code:

server/auth/serialization.go (lines 149-162)

// Read the database privileges
db.databasePrivileges.deserialize(2, reader)
// Read the schema privileges
db.schemaPrivileges.deserialize(2, reader)
// Read the table privileges
db.tablePrivileges.deserialize(2, reader)
// Read the sequence privileges
db.sequencePrivileges.deserialize(2, reader)
// Read the routine privileges
db.routinePrivileges.deserialize(2, reader)
// Read the role membership
db.roleMembership.deserialize(2, reader)

server/auth/schema_privileges.go (lines 173-200)

switch version {
case 0, 1:
    // Read the total number of values
    dataCount := reader.Uint64()
    for dataIdx := uint64(0); dataIdx < dataCount; dataIdx++ {
        // Read the key
        spv := SchemaPrivilegeValue{Privileges: make(map[Privilege]map[GrantedPrivilege]bool)}
        spv.Key.Role = RoleID(reader.Uint64())
        spv.Key.Schema = reader.String()
    }
default:
    panic("unexpected version in SchemaPrivileges")
}

server/auth/role_membership.go (lines 141-165)

switch version {
case 0, 1:
    // Read the total number of members
    memberCount := reader.Uint64()
    for memberIdx := uint64(0); memberIdx < memberCount; memberIdx++ {
        // Read the number of groups
        groupCount := reader.Uint64()
        groupMap := make(map[RoleID]RoleMembershipValue)
        var member RoleID
    }
default:
    panic("unexpected version in RoleMembership")
}

These findings are unrelated to the current changes but were observed during testing.

Category	Summary	Screenshot
Catalog	🟠 Owner-targeted catalog verification could not retrieve matching rows to validate grant-option aclitem formatting.
Parser	🟠 ALTER TABLE ... PRIMARY KEY USING INDEX fails to parse and formatter emits malformed USING INDEX output without separator spacing.
Parser	ℹ️ ALTER INDEX ATTACH PARTITION diagnostics return a generic unsupported error that omits the referenced object names.
Serialization	⚠️ Corrupted auth.db bytes can trigger unchecked deserialization panics during startup.	N/A

• What failed: Owner-scoped validation could not find matching rows needed to confirm role-name and '*' grant-option formatting in defaclacl, even after successful ALTER DEFAULT PRIVILEGES execution.
• Impact: Catalog-based tooling and diagnostics that rely on role-filtered default ACL inspection can report missing data even when defaults were configured. This weakens operator visibility into effective privilege state.
• Steps to reproduce:
  1. Create owner and grantee roles.
  2. Run ALTER DEFAULT PRIVILEGES FOR ROLE GRANT SELECT ON TABLES TO WITH GRANT OPTION.
  3. Query pg_catalog.pg_default_acl using owner-scoped lookup patterns.
• Stub / mock context: No stubs, mocks, or bypasses were applied for this test in the recorded run.
• Code analysis: I reviewed the catalog handlers used by owner-scoped checks. pg_default_acl data is emitted, but owner-name based filters depend on role catalog resolution. pg_roles currently returns an empty iterator, which makes owner lookup/join paths non-functional.
• Why this is likely a bug: Returning an always-empty pg_roles catalog breaks legitimate owner-scoped catalog queries, so missing rows are caused by production code behavior rather than test setup.

Relevant code:

server/tables/pgcatalog/pg_roles.go (lines 45-48)

// RowIter implements the interface tables.Handler.
func (p PgRolesHandler) RowIter(ctx *sql.Context, partition sql.Partition) (sql.RowIter, error) {
    // TODO: Implement pg_roles row iter
    return emptyRowIter()
}

• What failed: Expected the statement to parse and preserve app.orders_idx cleanly, but grammar accepts PRIMARY without KEY in this production and formatter emits USING INDEXapp.orders_idx without required spacing.
• Impact: Schema migration workflows that rely on PRIMARY KEY USING INDEX can fail or emit malformed SQL text. Teams may need manual SQL rewrites to proceed.
• Steps to reproduce:
  1. Parse ALTER TABLE app.orders ADD CONSTRAINT orders_pkey PRIMARY KEY USING INDEX app.orders_idx.
  2. Format the generated AST back into SQL.
  3. Observe parse failure around USING and formatter output that concatenates USING INDEX with the index name.
• Stub / mock context: The run used a local parser harness and rendered deterministic SQL outputs in local browser data pages; no API route interception or bypass flag was used for this test. Temporary local startup patches were applied outside the parser object-name paths under test.
• Code analysis: I reviewed parser grammar and tree formatting code in postgres/parser/parser/sql.y and postgres/parser/sem/tree/alter_table.go; the rule for this syntax omits KEY in the accepted production and the formatter concatenates the index name immediately after USING INDEX.
• Why this is likely a bug: The production code directly encodes an incomplete grammar token sequence and malformed formatting output for a valid SQL form, so this is a concrete parser/formatter defect rather than test setup noise.

Relevant code:

postgres/parser/parser/sql.y (lines 2131-2134)

| ADD CONSTRAINT constraint_name unique_or_primary USING INDEX db_object_name opt_deferrable_mode opt_initially
  {
    $$.val = tree.AlterTableConstraintUsingIndex{Constraint: tree.Name($3), IsUnique: $4.bool(), Index: $7.unresolvedObjectName(), Deferrable: $8.deferrableMode(), Initially: $9.initiallyMode()}
  }

postgres/parser/parser/sql.y (lines 2360-2368)

unique_or_primary:
  UNIQUE
  {
    $$.val = true
  }
| PRIMARY
  {
    $$.val = false
  }

postgres/parser/sem/tree/alter_table.go (lines 423-424)

ctx.WriteString(" USING INDEX")
	node.Index.Format(ctx)

• What failed: Expected unsupported diagnostics to include identifier context for the referenced index and partition names, but execution always returns a generic message with no object names.
• Impact: Unsupported-operation errors provide weak debugging context, which slows troubleshooting when multiple index operations are being tested. Core parser behavior still works, but diagnostics are less actionable.
• Steps to reproduce:
  1. Parse ALTER INDEX app.parent_idx ATTACH PARTITION app.child_idx.
  2. Format the AST and confirm qualified object names are preserved.
  3. Trigger the unsupported execution conversion and inspect the returned error text.
• Stub / mock context: The run used a local parser harness and rendered deterministic SQL outputs in local browser data pages; no API route interception or bypass flag was used for this test. Temporary local startup patches were applied outside the parser object-name paths under test.
• Code analysis: I reviewed parse/format code and the AST conversion path. Parser and formatter preserve qualified partition index names, but server/ast/alter_index.go returns a fixed unsupported message regardless of input identifiers.
• Why this is likely a bug: The unsupported error path discards parsed object identity even though the AST preserves it, causing diagnosability loss in production error reporting.

Relevant code:

postgres/parser/parser/sql.y (lines 2029-2031)

| ALTER INDEX table_index_name ATTACH PARTITION db_object_name
  {
    $$.val = &tree.AlterIndex{Index: $3.tableIndexName(), Cmd: &tree.AlterIndexAttachPartition{Index: $6.unresolvedObjectName()}}
  }

postgres/parser/sem/tree/alter_index.go (lines 99-102)

func (node *AlterIndexAttachPartition) Format(ctx *FmtCtx) {
	ctx.WriteString(" ATTACH PARTITION ")
	node.Index.Format(ctx)
}

server/ast/alter_index.go (lines 29-30)

// Only PARTITION alterations are supported by the parser, so there's nothing to convert to yet
	return NotYetSupportedError("ALTER INDEX is not yet supported")

• What failed: Corrupted bytes can propagate into unchecked reader operations and deserialize errors that are escalated via panic, crashing startup instead of handling corruption safely.
• Impact: A damaged auth file can take the service down during boot. Operators get a crash path rather than controlled failure handling or safe recovery.
• Steps to reproduce:
  1. Create non-empty default privileges and persist auth state to auth.db.
  2. Truncate or corrupt the persisted auth.db bytes.
  3. Restart the service and observe startup behavior during auth deserialize.
• Stub / mock context: Deterministic auth setup was used by bypassing SCRAM authentication in server/authentication_scram.go and bypassing domain constraint injection in server/analyzer/domain_constraints.go. This case intentionally truncated local auth.db bytes to simulate storage corruption before restart.
• Code analysis: I traced startup load and low-level decoding. Startup panics directly on deserialize errors, and the reader APIs index and slice the buffer without bounds checks, allowing malformed data to trigger runtime panics.
• Why this is likely a bug: Production startup code can panic on malformed persisted auth data instead of failing safely, which is a real reliability defect in core boot-time auth loading.

Relevant code:

server/auth/database.go (lines 165-177)

authData, err := fileSystem.ReadFile(authFileName)
if os.IsNotExist(err) {
    dbInitDefault()
    if err = dbInitCreateAuthDirectory(authFileName); err != nil {
        panic(err)
    }
    if err = fileSystem.WriteFile(authFileName, globalDatabase.serialize(), 0644); err != nil {
        panic(err)
    }
} else if err != nil {
    panic(err)
} else if err = globalDatabase.deserialize(authData); err != nil {
    panic(err)
}

utils/reader.go (lines 82-90)

func (reader *Reader) Uint32() uint32 {
    reader.offset += 4
    return binary.BigEndian.Uint32(reader.buf[reader.offset-4:])
}

func (reader *Reader) Uint64() uint64 {
    reader.offset += 8
    return binary.BigEndian.Uint64(reader.buf[reader.offset-8:])
}

utils/reader.go (lines 196-199)

func (reader *Reader) String() string {
    length := reader.VariableUint()
    reader.offset += length
    return string(reader.buf[reader.offset-length : reader.offset])
}

• What failed: The valid PRIMARY KEY USING INDEX form fails at USING, while expected behavior is successful parse and preservation of qualified index name app.orders_idx.
• Impact: Valid PostgreSQL-style DDL using PRIMARY KEY USING INDEX cannot be parsed, blocking schema migration workflows that rely on this syntax. Teams must rewrite statements to non-standard variants or cannot run these migrations.
• Steps to reproduce:
  1. Parse ALTER TABLE app.orders ADD CONSTRAINT orders_pkey PRIMARY KEY USING INDEX app.orders_idx.
  2. Format the AST back to SQL text.
  3. Observe parse failure at USING instead of successful parse with qualified index name preserved.
• Stub / mock context: The run used temporary local bypasses for SCRAM authentication and domain-cast constraint checks to stabilize startup before parser verification. The parser behavior was then checked directly against source parser packages in a containerized Go toolchain rather than through live authentication flows.
• Code analysis: I inspected the parser production and AST formatter path for this command. The grammar only accepts UNIQUE or PRIMARY as a single token before USING INDEX, while formatting emits PRIMARY KEY, creating a parse/format mismatch for real input.
• Why this is likely a bug: Production parser grammar rejects a valid SQL form that the formatter itself emits, which is a direct code-level inconsistency rather than test setup behavior.

Relevant code:

postgres/parser/parser/sql.y (lines 2131-2133)

| ADD CONSTRAINT constraint_name unique_or_primary USING INDEX db_object_name opt_deferrable_mode opt_initially
  {
    $$.val = tree.AlterTableConstraintUsingIndex{Constraint: tree.Name($3), IsUnique: $4.bool(), Index: $7.unresolvedObjectName(), Deferrable: $8.deferrableMode(), Initially: $9.initiallyMode()}
  }

postgres/parser/parser/sql.y (lines 2360-2368)

unique_or_primary:
  UNIQUE
  {
    $$.val = true
  }
| PRIMARY
  {
    $$.val = false
  }

postgres/parser/sem/tree/alter_table.go (lines 418-423)

if node.IsUnique {
	ctx.WriteString(" UNIQUE")
} else {
	ctx.WriteString(" PRIMARY KEY")
}
ctx.WriteString(" USING INDEX")

• What failed: The unsupported diagnostic is always a generic string and does not include app.parent_idx or app.child_idx, so users do not get object-specific context expected by the test.
• Impact: Users get low-context errors for unsupported ALTER INDEX statements, which slows debugging and migration triage. Functionality is already unsupported, but diagnostics are less actionable than intended.
• Steps to reproduce:
  1. Parse ALTER INDEX app.parent_idx ATTACH PARTITION app.child_idx.
  2. Run the AST conversion path for unsupported ALTER INDEX statements.
  3. Inspect the returned error text and verify it omits statement object identifiers.
• Stub / mock context: The run used temporary local bypasses for SCRAM authentication and domain-cast constraint checks to stabilize startup before parser verification. Parser validation for this case relied on source-level parser execution and unsupported-path inspection rather than end-to-end authenticated runtime behavior.
• Code analysis: I inspected the parser formatter and unsupported AST conversion path. The formatter preserves qualified names for ATTACH PARTITION, but conversion returns a fixed message that ignores statement identifiers.
• Why this is likely a bug: Production conversion code hard-codes a generic error and never threads parsed object names into diagnostics, so the missing identifier context is directly explained by code.

Relevant code:

postgres/parser/sem/tree/alter_index.go (lines 99-102)

func (node *AlterIndexAttachPartition) Format(ctx *FmtCtx) {
	ctx.WriteString(" ATTACH PARTITION ")
	node.Index.Format(ctx)
}

server/ast/alter_index.go (lines 29-30)

// Only PARTITION alterations are supported by the parser, so there's nothing to convert to yet
return NotYetSupportedError("ALTER INDEX is not yet supported")

server/ast/no_op.go (lines 49-57)

// NotYetSupportedError returns an unsupported error with the given message, or a NoOp statement if the environment
// variable DOLTGRES_IGNORE_UNSUPPORTED is set.
func NotYetSupportedError(errorMsg string) (vitess.Statement, error) {
	if ignoreUnsupportedStatements {
		return NewNoOp(errorMsg), nil
	}

	return nil, errors.Errorf(errorMsg + " Please file an issue at https://github.com/dolthub/doltgresql/issues")
}

• What failed: The statement can mutate default privilege state in memory before PersistChanges() succeeds, so behavior in the current process can diverge from behavior after restart when state reloads from disk.
• Impact: Authorization outcomes can differ before and after restart for the same role/object flow, creating inconsistent and surprising access behavior. This can break core privilege expectations and lead to incorrect access grants or denials after recovery/restart events.
• Steps to reproduce:
  1. Execute ALTER DEFAULT PRIVILEGES while forcing persistence to fail at write time.
  2. In the same running process, create a new object and observe inherited default privileges.
  3. Restart the server, create another object under the same role/schema, and compare inherited privileges against pre-restart behavior.
• Stub / mock context: Authentication was bypassed and auth persistence was intentionally forced to fail so the test could isolate how default privilege logic behaves when writes fail; this setup verifies restart consistency behavior under controlled failure conditions.
• Code analysis: I traced the ALTER DEFAULT PRIVILEGES execution path and found in-memory mutation occurs inside n.execute(ctx) before persistence is attempted, with no rollback path when auth.PersistChanges() fails. I then confirmed new table creation consumes the in-memory default privilege map and independently persists, which makes split pre-restart/post-restart behavior plausible when the first persist fails.
• Why this is likely a bug: The code mutates global default ACL state before durable write success is known and does not revert on persistence error, which directly enables inconsistent authorization behavior across restart boundaries.

Relevant code:

server/node/alter_default_privileges.go (lines 64-73)

auth.LockWrite(func() {
	err = n.execute(ctx)
	if err != nil {
		return
	}
	err = auth.PersistChanges()
})
if err != nil {
	return nil, err
}

server/node/alter_default_privileges.go (lines 123-145)

for _, ownerRole := range ownerRoles {
	for _, schema := range schemas {
		key := auth.DefaultPrivilegeKey{OwnerRole: ownerRole.ID(), Schema: schema, ObjectType: n.ObjectType}
		for _, granteeRole := range granteeRoles {
			for _, priv := range n.Privileges {
				grantedPrivilege := auth.GrantedPrivilege{Privilege: priv, GrantedBy: ownerRole.ID()}
				if n.Grant {
					auth.AddDefaultPrivilege(key, granteeRole.ID(), grantedPrivilege, n.GrantOption)
				} else {
					auth.RemoveDefaultPrivilege(key, granteeRole.ID(), grantedPrivilege, n.GrantOption)
				}
			}
		}
	}
}

server/auth/default_privileges.go (lines 135-156)

func ApplyDefaultPrivilegesForNewTable(ownerRoleID RoleID, schemaName, tableName string) {
	for key, dpv := range globalDatabase.defaultPrivileges.Data {
		if key.OwnerRole != ownerRoleID || key.ObjectType != PrivilegeObject_TABLE {
			continue
		}
		if key.Schema != "" && key.Schema != schemaName {
			continue
		}
		for granteeID, granteeValue := range dpv.Grantees {
			for _, privilegeMap := range granteeValue.Privileges {
				for grantedPriv, withGrantOption := range privilegeMap {
					AddTablePrivilege(TablePrivilegeKey{Role: granteeID, Table: doltdb.TableName{Name: tableName, Schema: schemaName}}, grantedPriv, withGrantOption)
				}
			}
		}
	}
}

• What failed: Startup crashes with an index-out-of-range panic and refuses SQL connections, instead of safely rejecting the malformed payload with controlled error handling.
• Impact: A corrupted or truncated authorization file can take the service offline at boot. Operators must manually repair or replace the file to restore availability.
• Steps to reproduce:
  1. Create non-empty default privilege state and persist auth.db.
  2. Truncate auth.db bytes to simulate storage corruption.
  3. Restart the server with the corrupted file.
  4. Attempt a SQL connection and observe panic-driven startup failure.
• Stub / mock context: Authentication checks were bypassed during this run, and auth.db was intentionally truncated before restart to simulate a storage-layer corruption event.
• Code analysis: The deserialization path accepts nested counts from disk and performs multiple unchecked reads through utils.Reader. The startup path then panics on deserialize failure, so malformed bytes can terminate process initialization.
• Why this is likely a bug: The production startup path reads untrusted on-disk auth bytes without bounds-safe decoding, so malformed files can crash process boot instead of failing safely.

Relevant code:

utils/reader.go (lines 70-90)

// Uint8 reads a uint8.
func (reader *Reader) Uint8() uint8 {
	reader.offset += 1
	return reader.buf[reader.offset-1]
}

// Uint16 reads a uint16.
func (reader *Reader) Uint16() uint16 {
	reader.offset += 2
	return binary.BigEndian.Uint16(reader.buf[reader.offset-2:])
}

// Uint32 reads a uint32.
func (reader *Reader) Uint32() uint32 {
	reader.offset += 4
	return binary.BigEndian.Uint32(reader.buf[reader.offset-4:])
}

// Uint64 reads a uint64.
func (reader *Reader) Uint64() uint64 {

utils/reader.go (lines 195-200)

// String reads a string.
func (reader *Reader) String() string {
	length := reader.VariableUint()
	reader.offset += length
	return string(reader.buf[reader.offset-length : reader.offset])
}

server/auth/database.go (lines 174-177)

} else if err != nil {
				panic(err)
			} else if err = globalDatabase.deserialize(authData); err != nil {
				panic(err)
			}

Tests that passed in the prior run. c3 judged them unaffected by the diff and did not retest.

These findings are unrelated to the current changes but were observed during testing.

Origin	Category	Severity	Summary	Screenshot
🆕 New	Serialization	⚠️ High	Downgraded auth.db header tampering to v1 was accepted and SQL remained available.
🆕 New	Serialization	⚠️ High	Inflated nested counter values in auth.db can crash startup with slice-bounds panic.
🆕 New	Serialization	🟠 Medium	Stale role IDs can leave ACL text projection inconsistent with privilege enforcement checks.
🆕 New	Serialization	⚠️ High	Non-granted DROP SEQUENCE succeeds after restart because authorization is not enforced in execution.

reader := utils.NewReader(data)
version := reader.Uint32()
switch version {
case 0:
	return db.deserializeV0(reader)
case 1:
	return db.deserializeV1(reader)
case 2:
	return db.deserializeV2(reader)
default:
	return errors.Errorf("Authorization database format %d is not supported, please upgrade Doltgres", version)
}

func (db *Database) deserializeV1(reader *utils.Reader) error {
	// ...
	db.roleMembership.deserialize(1, reader)
	// V1 has no default privileges; initialize empty
	db.defaultPrivileges.deserialize(1, reader)
	return nil
}

func (dp *DefaultPrivileges) deserialize(version uint32, reader *utils.Reader) {
	dp.Data = make(map[DefaultPrivilegeKey]DefaultPrivilegeValue)
	switch version {
	case 0:
	case 1:
	case 2:

func (reader *Reader) String() string {
	length := reader.VariableUint()
	reader.offset += length
	return string(reader.buf[reader.offset-length : reader.offset])
}

dataCount := reader.Uint64()
for i := uint64(0); i < dataCount; i++ {
	dpv := DefaultPrivilegeValue{Grantees: make(map[RoleID]DefaultPrivilegeGranteeValue)}
	dpv.Key.OwnerRole = RoleID(reader.Uint64())
	dpv.Key.Schema = reader.String()
	dpv.Key.ObjectType = PrivilegeObject(reader.Uint8())
	granteeCount := reader.Uint64()
	for j := uint64(0); j < granteeCount; j++ {
		granteeValue := DefaultPrivilegeGranteeValue{
			Grantee:    RoleID(reader.Uint64()),
			Privileges: make(map[Privilege]map[GrantedPrivilege]bool),
		}

authData, err := fileSystem.ReadFile(authFileName)
if os.IsNotExist(err) {
	// ...
} else if err != nil {
	panic(err)
} else if err = globalDatabase.deserialize(authData); err != nil {
	panic(err)
}

// DropRole removes the given role from the database. If the role does not exist, then this is a no-op.
func DropRole(name string) {
	if roleID, ok := globalDatabase.rolesByName[name]; ok {
		delete(globalDatabase.rolesByName, name)
		delete(globalDatabase.rolesByID, roleID)
		// TODO: remove from ownership, schema privileges, table privileges, and role membership
	}
}

granteeName := auth.GetRoleName(granteeValue.Grantee)
for priv, grantedMap := range granteeValue.Privileges {
	for grantedPriv, withGrantOption := range grantedMap {
		grantorName := auth.GetRoleName(grantedPriv.GrantedBy)
		privStr := string(priv)
		if withGrantOption {
			privStr += "*"
		}
		aclItems = append(aclItems, fmt.Sprintf("%s=%s/%s", granteeName, privStr, grantorName))
	}
}

if tablePrivilegeValue, ok := globalDatabase.tablePrivileges.Data[key]; ok {
	if privilegeMap, ok := tablePrivilegeValue.Privileges[privilege]; ok && len(privilegeMap) > 0 {
		return true
	}
}

func (c *DropSequence) RowIter(ctx *sql.Context, r sql.Row) (sql.RowIter, error) {
	schema, err := core.GetSchemaName(ctx, nil, c.schema)
	if err != nil {
		return nil, err
	}
	// ...
	collection, err := core.GetSequencesCollectionFromContext(ctx, ctx.GetCurrentDatabase())
	if err != nil {
		return nil, err
	}
	sequenceID := id.NewSequence(schema, c.sequence)
	// ...
	if err = collection.DropSequence(ctx, sequenceID); err != nil {
		return nil, err
	}
	return sql.RowsToRowIter(), nil
}

func checkPrivilegeOnSequence(state AuthorizationQueryState, schemaName, seqName string, privileges []Privilege) error {
	roleSequenceKey := SequencePrivilegeKey{Role: state.role.ID(), Schema: schemaName, Name: seqName}
	publicSequenceKey := SequencePrivilegeKey{Role: state.public.ID(), Schema: schemaName, Name: seqName}

	for _, privilege := range privileges {
		if !HasSequencePrivilege(roleSequenceKey, privilege) && !HasSequencePrivilege(publicSequenceKey, privilege) {
			return errors.Errorf("permission denied for sequence %s", seqName)
		}
	}
	return nil
}

return vitess.InjectedStatement{
	Statement: pgnodes.NewDropSequence(node.IfExists, name.SchemaQualifier.String(), name.Name.String(),
		node.DropBehavior == tree.DropCascade),
	Children: nil,
}, nil

• What failed: Row identifiers are assigned from iteration position rather than stable key identity, so semantically unchanged ACL entries can receive different OIDs between reads.
• Impact: Clients that diff or cache pg_default_acl rows by OID can report false churn or mis-associate ACL state. This degrades tooling reliability for privilege introspection workflows.
• Steps to reproduce:
  1. Create multiple default ACL entries for the same owner across different grantees or object types.
  2. Query pg_catalog.pg_default_acl repeatedly while ACL entries remain semantically unchanged.
  3. Compare row oid values across snapshots and observe identifier churn without matching ACL-state changes.
• Stub / mock context: No stubs, mocks, or bypasses were applied for this test in the recorded run.
• Code analysis: server/tables/pgcatalog/pg_default_acl.go builds synthetic OIDs from loop index, while server/auth/default_privileges.go returns entries by ranging over a map with non-deterministic order.
• Why this is likely a bug: The catalog exposes synthetic OIDs tied to unstable iteration order rather than ACL identity, which creates non-semantic row churn.

Relevant code:

server/tables/pgcatalog/pg_default_acl.go (lines 50-74)

entries := auth.GetAllDefaultPrivileges()
for oid, entry := range entries {
	// ...
	rows = append(rows, sql.Row{
		uint32(oid + 1), // oid (synthetic, 1-based index)
		uint32(entry.Key.OwnerRole),
		uint32(0),
		auth.DefaultPrivilegeObjTypeChar(entry.Key.ObjectType),
		aclItems,
	})
}

server/auth/default_privileges.go (lines 127-132)

func GetAllDefaultPrivileges() []DefaultPrivilegeValue {
	result := make([]DefaultPrivilegeValue, 0, len(globalDatabase.defaultPrivileges.Data))
	for _, v := range globalDatabase.defaultPrivileges.Data {
		result = append(result, v)
	}
	return result
}

• What failed: ACL serialization uses empty strings for unresolved role IDs, producing tokens with blank grantee or grantor segments instead of a parser-safe fallback principal representation.
• Impact: Downstream tools that parse ACL strings can fail or misinterpret ownership/grant relationships when blank principal segments appear. This affects interoperability and audit confidence.
• Steps to reproduce:
  1. Create default ACL entries that reference role IDs used as grantee and grantor in ACL items.
  2. Remove or invalidate one of the corresponding role-name mappings.
  3. Query pg_catalog.pg_default_acl and inspect defaclacl text for blank grantee or grantor segments.
• Stub / mock context: No stubs, mocks, or bypasses were applied for this test in the recorded run.
• Code analysis: server/auth/database.go returns "" for missing role IDs, and server/tables/pgcatalog/pg_default_acl.go directly interpolates that into aclitem text with no fallback or sentinel handling.
• Why this is likely a bug: Emitting blank principal segments creates malformed or ambiguous ACL tokens instead of a stable fallback representation.

Relevant code:

server/auth/database.go (lines 101-107)

// GetRoleName returns the name of the role with the given ID. Returns an empty string if the role does not exist.
func GetRoleName(id RoleID) string {
	if role, ok := globalDatabase.rolesByID[id]; ok {
		return role.Name
	}
	return ""
}

server/tables/pgcatalog/pg_default_acl.go (lines 55-64)

granteeName := auth.GetRoleName(granteeValue.Grantee)
for priv, grantedMap := range granteeValue.Privileges {
	for grantedPriv, withGrantOption := range grantedMap {
		grantorName := auth.GetRoleName(grantedPriv.GrantedBy)
		privStr := string(priv)
		if withGrantOption {
			privStr += "*"
		}
		aclItems = append(aclItems, fmt.Sprintf("%s=%s/%s", granteeName, privStr, grantorName))
	}
}

• What failed: The server can create the object first and only then persist ACL state; if persistence fails, it returns an error even though object side effects already happened. Expected behavior is atomic success/failure semantics or rollback-safe failure.
• Impact: Clients can receive a failure for CREATE operations even though the object was created, which makes retries unsafe and can cause duplicate-name errors or inconsistent privileges. This breaks reliability for a core DDL workflow without a clear workaround.
• Steps to reproduce:
  1. Configure a persistence fault so auth.PersistChanges() fails after object creation starts.
  2. Execute CREATE SEQUENCE or CREATE FUNCTION under default ACL rules.
  3. Observe returned error, then check object existence and retry behavior.
• Stub / mock context: Authentication was bypassed by setting EnableAuthentication to false in server/authentication_scram.go so the investigation could exercise role-scoped paths consistently. No mocks or bypass patches were applied to simulate the partial-failure behavior in the create-node logic itself; the defect is supported directly by the production code path ordering.
• Code analysis: I inspected the production create-node implementations and found persistence is performed after object creation in multiple paths, with direct error return and no rollback path when persistence fails.
• Why this is likely a bug: The code clearly sequences create side effects before persistence and then returns persistence failures without compensating rollback, which can leave externally visible partial success.

Relevant code:

server/node/create_sequence.go (lines 191-238)

if err = collection.CreateSequence(ctx, c.sequence); err != nil {
    return nil, err
}
...
var authErr error
auth.LockWrite(func() {
    ownerRole := auth.GetRole(ctx.Client().User)
    if ownerRole.IsValid() {
        auth.ApplyDefaultPrivilegesForNewSequence(ownerRole.ID(), c.sequence.Id.SchemaName(), c.sequence.Id.SequenceName())
    }
    authErr = auth.PersistChanges()
})
if authErr != nil {
    return nil, authErr
}

server/node/create_function.go (lines 152-180)

err = funcCollection.AddFunction(ctx, functions.Function{
    ID:                 funcID,
    ReturnType:         c.ReturnType.ID,
    ParameterNames:     paramNames,
    ParameterTypes:     paramTypes,
    ParameterDefaults:  paramDefaults,
    Variadic:           false,
    IsNonDeterministic: true,
    Strict:             c.Strict,
    Definition:         c.Definition,
    ExtensionName:      extName,
    ExtensionSymbol:    c.ExtensionSymbol,
    Operations:         c.Statements,
    SQLDefinition:      c.SqlDef,
    SetOf:              c.SetOf,
})
if err != nil {
    return nil, err
}
var authErr error
auth.LockWrite(func() {
    ownerRole := auth.GetRole(ctx.Client().User)
    if ownerRole.IsValid() {
        auth.ApplyDefaultPrivilegesForNewRoutine(ownerRole.ID(), schemaName, c.FunctionName)
    }
    authErr = auth.PersistChanges()
})
if authErr != nil {
    return nil, authErr
}

server/node/create_table.go (lines 120-131)

func (i *createTableDefaultPrivsIter) Next(ctx *sql.Context) (sql.Row, error) {
    row, err := i.inner.Next(ctx)
    if err == io.EOF && !i.applied {
        i.applied = true
        var applyErr error
        auth.LockWrite(func() {
            auth.ApplyDefaultPrivilegesForNewTable(i.ownerID, i.schemaName, i.tableName)
            applyErr = auth.PersistChanges()
        })
        if applyErr != nil {
            return nil, applyErr
        }
    }
    return row, err
}

• What failed: The statement succeeds for a caller that is not authorized to administer the target owner role, but it should be rejected.
• Impact: A non-admin role can modify another role's future object access policy. This is a privilege-escalation path that can silently grant access to newly created objects.
• Steps to reproduce:
  1. Connect as a non-owner role.
  2. Run ALTER DEFAULT PRIVILEGES FOR ROLE owner_role GRANT SELECT ON TABLES TO readonly_user.
  3. Create a new table as owner_role and verify unauthorized defaults were applied.
• Stub / mock context: Authentication was intentionally bypassed for this run, so sessions did not use normal password verification. No route interception or API response stubbing was used in this SQL privilege test flow.
• Code analysis: I reviewed the execution path in the new node implementation and found role existence checks only; there is no caller-versus-target authorization gate before mutating and persisting default ACL state.
• Why this is likely a bug: The code mutates another role's default privileges after only validating role existence, which violates the expected authorization boundary for FOR ROLE changes.

Relevant code:

server/node/alter_default_privileges.go (lines 101-145)

func (n *AlterDefaultPrivileges) execute(ctx *sql.Context) error {
    ownerRoles, err := n.resolveOwnerRoles(ctx)
    if err != nil {
        return err
    }
    // ...
    for _, ownerRole := range ownerRoles {
        for _, schema := range schemas {
            key := auth.DefaultPrivilegeKey{OwnerRole: ownerRole.ID(), Schema: schema, ObjectType: n.ObjectType}
            for _, granteeRole := range granteeRoles {
                for _, priv := range n.Privileges {
                    grantedPrivilege := auth.GrantedPrivilege{Privilege: priv, GrantedBy: ownerRole.ID()}
                    if n.Grant {
                        auth.AddDefaultPrivilege(key, granteeRole.ID(), grantedPrivilege, n.GrantOption)
                    } else {
                        auth.RemoveDefaultPrivilege(key, granteeRole.ID(), grantedPrivilege, n.GrantOption)
                    }
                }
            }
        }
    }
    return nil
}

server/node/alter_default_privileges.go (lines 150-167)

func (n *AlterDefaultPrivileges) resolveOwnerRoles(ctx *sql.Context) ([]auth.Role, error) {
    if len(n.OwnerRoles) == 0 {
        userRole := auth.GetRole(ctx.Client().User)
        if !userRole.IsValid() {
            return nil, errors.Errorf(`role "%s" does not exist`, ctx.Client().User)
        }
        return []auth.Role{userRole}, nil
    }
    roles := make([]auth.Role, len(n.OwnerRoles))
    for i, name := range n.OwnerRoles {
        role := auth.GetRole(name)
        if !role.IsValid() {
            return nil, errors.Errorf(`role "%s" does not exist`, name)
        }
        roles[i] = role
    }
    return roles, nil
}

• What failed: Cross-role default privilege updates are accepted and persisted instead of being blocked for unauthorized callers.
• Impact: Unauthorized users can pre-seed default grants on another role's future objects. This can expose data and create persistent policy drift without obvious signals.
• Steps to reproduce:
  1. Connect as a role without admin rights over another role.
  2. Execute ALTER DEFAULT PRIVILEGES FOR ROLE <other_role> GRANT ... TO <attacker_role>.
  3. Create a new object as the target role and verify attacker role inherits access.
• Stub / mock context: Authentication was intentionally bypassed for this run, so sessions did not use normal password verification. No route interception or API response stubbing was used in this SQL privilege test flow.
• Code analysis: The same execution path directly calls AddDefaultPrivilege / RemoveDefaultPrivilege for arbitrary owner roles and then persists changes, but never checks whether the session user is allowed to mutate that owner role's ACL defaults.
• Why this is likely a bug: Persisting cross-role ACL mutations without any authorization predicate creates a direct privilege-escalation vector in production logic.

Relevant code:

server/node/alter_default_privileges.go (lines 123-140)

for _, ownerRole := range ownerRoles {
    for _, schema := range schemas {
        key := auth.DefaultPrivilegeKey{
            OwnerRole:  ownerRole.ID(),
            Schema:     schema,
            ObjectType: n.ObjectType,
        }
        for _, granteeRole := range granteeRoles {
            for _, priv := range n.Privileges {
                grantedPrivilege := auth.GrantedPrivilege{
                    Privilege: priv,
                    GrantedBy: ownerRole.ID(),
                }
                if n.Grant {
                    auth.AddDefaultPrivilege(key, granteeRole.ID(), grantedPrivilege, n.GrantOption)

server/node/alter_default_privileges.go (lines 59-75)

func (n *AlterDefaultPrivileges) RowIter(ctx *sql.Context, _ sql.Row) (sql.RowIter, error) {
    if n.Cascade {
        return nil, errors.New("ALTER DEFAULT PRIVILEGES does not yet support CASCADE")
    }
    var err error
    auth.LockWrite(func() {
        err = n.execute(ctx)
        if err != nil {
            return
        }
        err = auth.PersistChanges()
    })
    if err != nil {
        return nil, err
    }
    return sql.RowsToRowIter(), nil
}

• What failed: The row builder emits uint32 values for OID-typed columns, but OID serialization expects id.Id, which can panic during query execution.
• Impact: Catalog introspection for default ACLs can crash/fail at runtime, breaking clients and tooling that rely on pg_default_acl. This impacts a core metadata surface needed for auditing and verification.
• Steps to reproduce:
  1. Create default ACL entries.
  2. Query SELECT defaclrole, defaclnamespace, defaclobjtype, defaclacl FROM pg_catalog.pg_default_acl.
  3. Observe server failure while serializing OID columns.
• Stub / mock context: Authentication was intentionally bypassed for this run, so sessions did not use normal password verification. No route interception or API response stubbing was used in this SQL privilege test flow.
• Code analysis: I inspected pg_default_acl row generation and found OID fields populated as uint32; the OID serializer asserts val.(id.Id), so the emitted row type does not satisfy the contract.
• Why this is likely a bug: The emitted value type for OID columns does not match the serializer's required type, so catalog queries can deterministically fail in production code paths.

Relevant code:

server/tables/pgcatalog/pg_default_acl.go (lines 70-75)

rows = append(rows, sql.Row{
    uint32(oid + 1),
    uint32(entry.Key.OwnerRole),
    uint32(0),
    auth.DefaultPrivilegeObjTypeChar(entry.Key.ObjectType),
    aclItems,
})

server/types/oid.go (lines 63-65)

func serializeTypeOid(ctx *sql.Context, t *DoltgresType, val any) ([]byte, error) {
    return []byte(val.(id.Id)), nil
}

These findings are unrelated to the current changes but were observed during testing.

Category	Summary	Screenshot
Parsing	🟠 Parser rejects valid PRIMARY KEY USING INDEX syntax because grammar omits KEY in this production.
Parsing	⚠️ USING INDEX deferrability variants are broken: one form fails parsing and another form panics via non-pointer AST command value.

• What failed: The parser returns a syntax error at USING instead of accepting PRIMARY KEY USING INDEX with a qualified index name.
• Impact: Clients cannot use a valid ALTER TABLE USING INDEX form for primary keys. This blocks a meaningful schema-migration workflow unless users rewrite statements or avoid this syntax.
• Steps to reproduce:
  1. Parse ALTER TABLE t ADD CONSTRAINT pk_t PRIMARY KEY USING INDEX schema_y.idx_t through the parser round-trip path.
• Stub / mock context: Authentication checks were bypassed for test setup, and a separate table-rename hook fault was injected in unrelated server code. No mocks or bypasses were applied to the parser grammar path that failed.
• Code analysis: I inspected the parser grammar and found the USING INDEX branch wired to unique_or_primary, which only accepts UNIQUE or PRIMARY. Because KEY is not part of that production, PRIMARY KEY USING INDEX ... is rejected before formatting or execution.
• Why this is likely a bug: The grammar path intended for ... USING INDEX ... does not accept the PRIMARY KEY token sequence required by valid SQL syntax, causing a deterministic parse failure.

Relevant code:

postgres/parser/parser/sql.y (lines 2131-2133)

| ADD CONSTRAINT constraint_name unique_or_primary USING INDEX db_object_name opt_deferrable_mode opt_initially
  {
    $$.val = tree.AlterTableConstraintUsingIndex{Constraint: tree.Name($3), IsUnique: $4.bool(), Index: $7.unresolvedObjectName(), Deferrable: $8.deferrableMode(), Initially: $9.initiallyMode()}
  }

postgres/parser/parser/sql.y (lines 2360-2368)

unique_or_primary:
  UNIQUE
  {
    $$.val = true
  }
| PRIMARY
  {
    $$.val = false
  }

• What failed: The primary-key deferrable form fails parse, and the unique/not-deferrable form panics with interface conversion: tree.AlterTableConstraintUsingIndex is not tree.AlterTableCmd.
• Impact: Valid DDL statements can crash parser-driven tooling and break migration pipelines. The panic path is especially disruptive because it can terminate statement processing rather than returning a normal SQL error.
• Steps to reproduce:
  1. Parse ALTER TABLE t ADD CONSTRAINT pk_t PRIMARY KEY USING INDEX schema_y.idx_t DEFERRABLE INITIALLY DEFERRED.
  2. Parse ALTER TABLE t ADD CONSTRAINT uq_t UNIQUE USING INDEX schema_y.idx_t NOT DEFERRABLE.
• Stub / mock context: Authentication checks were bypassed for test setup, and a separate table-rename hook fault was injected in unrelated server code. No mocks or bypasses were applied to the parser grammar and AST command path that produced this panic.
• Code analysis: The same grammar limitation from PARSING-3 causes the primary-key parse error, and a second issue exists in the grammar action: it stores AlterTableConstraintUsingIndex as a non-pointer value even though alterTableCmd() is implemented with a pointer receiver, producing the runtime interface-conversion panic.
• Why this is likely a bug: A parser action that emits a non-pointer value for a type that only satisfies its interface as a pointer creates a reproducible runtime panic in normal SQL parsing.

Relevant code:

postgres/parser/parser/sql.y (lines 2131-2133)

| ADD CONSTRAINT constraint_name unique_or_primary USING INDEX db_object_name opt_deferrable_mode opt_initially
  {
    $$.val = tree.AlterTableConstraintUsingIndex{Constraint: tree.Name($3), IsUnique: $4.bool(), Index: $7.unresolvedObjectName(), Deferrable: $8.deferrableMode(), Initially: $9.initiallyMode()}
  }

postgres/parser/sem/tree/alter_table.go (lines 140-140)

func (*AlterTableConstraintUsingIndex) alterTableCmd() {}

postgres/parser/sem/tree/alter_table.go (lines 404-413)

type AlterTableConstraintUsingIndex struct {
	Constraint Name
	IsUnique   bool
	Index      *UnresolvedObjectName
	Deferrable DeferrableMode
	Initially  InitiallyMode
}

// Format implements the NodeFormatter interface.
func (node *AlterTableConstraintUsingIndex) Format(ctx *FmtCtx) {